Internet Info 1993/Internet Info CD-ROM (Walnut Creek) (1993).iso/inet/ietf/acct/acct-minutes-90may.txt

Text File | 1993-02-17 | 13.1 KB | 360 lines

CURRENT_MEETING_REPORT_



Reported by Cindy Mills/ BBN

Summary

This was the first meeting of the Internet Accounting Working Group.  We
outlined a hierarchical architecture for accounting within routers and
discussed the types of meters to be used at each level.

Agenda

   o Accounting Architecture
   o Technical Reports
      -  Internet Accounting Model
      -  Liaison Activities (ANTF, OSI)
   o Open Discussion
   o Working Group Administration
      -  Review Charter & Minutes
      -  Identify and Assign Action Items

ACCOUNTING ARCHITECTURE

Due to performance constraints and the explosion in complexity, we
believe that it is not practical to perform detailed accounting to the
user-id level within all networks.  [Ed.  The reasons should be
documented in the Meter Services Document.]

Therefore we identified 4 levels of accounting interest/architecture:



Backbones/National ---------------------------
                         /        \
Regional          ------------  --------------
                      /  \   \ /  /   \
Stub/Enterprise     ---  ---  ---  ---  ---

Host



Note that mesh architectures can also be built out of these components.
Each network performs accounting functions for its immediate subscribers
/ connections.  Subscribers come in two flavors - subscriber networks
and subscriber hosts (end-users from the networking perspective).

We define backbone networks as bulk carriers that have only other
networks as subscribers.  Individual hosts are not directly connected to
a backbone.

                                   1






Backbones and regionals are closely related, and differ only in size,
the number of networks connected via each port, and ``geographical''
coverage.  Smaller Regionals may also have a few directly connected
hosts, acting as hybrid regional/stub networks.  We consider a regional
network as a subscriber network to the backbone.

Stub networks have hosts as direct connects, although they may be
combined by Enterprise networks treated in the same fashion as stub
networks.  For the stub/enterprise network provider, hosts are the
end-users, the accountable entities.  For the stub/enterprise network
provider, host addresses are the finest-granularity accountable entities
available at the IP level.

Hosts are ultimately responsible for identifying the end user.  This
information may be shared with the network, but it is the host's
responsibility to do so.  Host accounting is not discussed in detail,
since homogeneous Internet Accounting is most practical at the network
provider level, and should be performed within the network routers under
the control of the network provider.  (After all, the host is the
customer, and if I were selling network services.  I'm not sure I'd rely
on the customer to tell me how much he owes without having a mechanism
to keep the customer honest...)  In addition, implementing accounting in
the routers spares us from requiring that each host variation (various
hardware platforms and operating system versions) retrofit TCP/IP
implementations to include accounting as a condition for being attached
to a network which relies on accounting information.

ENTITIES: Each of the higher-level network (backbone and regional)
account for two sets of entities - one set corresponds to the network's
immediate subscribers and a parallel set (optional?)  covers the
subscribers of the network below.  This two-tiered system enables:


   o verification between provider and subscriber
   o reconstruction of accounting information around a single transit
     network which does not perform accounting functions.


Backbone Level Entities:    Adjacent Network (Port),Source/Dest Net Number
Regional Level Entities:    Src/Dest Network Number,Src/Dest Host Adr
Stub Level Entities:        Source/Dest Host Address
                           (End-user ID pair optional)
Host Level Entities:        Operating System dependent.Use OS accounting.



This allocation of accountable entities to network levels bears further
examination.  Particularly, it is important to understand what
complexity is accounting introduces at each network level.

Backbone Level Complexity:  Collects by port ID, and can further
subdivide by network numbers from the IP address.

                                   2






Regional Level Complexity:  Collects by host address pair only, since
network numbers can be derived from the host traffic matrix off-line.

Stub Complexity:  Collect host address pair in any case.  Approaches:


  1. Leave all else up to the local stub network and proprietary means
     if further information is required.
  2. Define IP option containing accounting information.
  3. Piggyback on the policy-based routing option and recommend how to
     use it.


Note on including destination addresses in the entity identifier:
Maintaining a traffic matrix at all levels seems to be a fair amount of
overhead, but destination information is required so often that it seems
reasonable to include it.  This way policy arrangements about who is
billed for communicating pairs can be independent of the originator of
the traffic.

SUB-ENTITIES: If we are aggregating information, the counts attributed
to a single entity may need sub-categories.  Suggested sub-categories
are:

   o protocol type
   o quality of service
   o types of counts

TYPES OF COUNTS: All networks count both packets and bytes for the
accountable entities.

TIME-OF-DAY: We need to be able to register start and stop times of
flows.  These trigger times should automatically start new aggregations
for the affected aggregate meters (i.e.  cause meters to send their data
along with the start and end times, and restart the meter at 0.).
QUALITY OF SERVICE: Unresolved.  What quality of service items should we
be able to specify?  QOS distinctions come in many forms.  For services
such as throughput, reliability, and delay there is a question of how
detailed the information should be about:

   o what level of service was requested
   o what level of service was offered (negotiated)
   o what level of service was actually provided (considering outages,
     etc.)

Technical Reports


  1. INTERNET ACCOUNTING MODEL
     See attached slides
  2. LIASON ACTIVITIES
     The ANSI Accounting WG has OSI Accounting Drafts available.

                                   3






   Report on April Autonomous Network Task Force (ANTF) Meeting on
   Internet Billing:

     o Billing Models discussed:
       -  Fixed Fee
       -  Usage Sensitive Billing
       -  Quality of Service Sensitive Billing
       -  Quotas
       -  Subsidy Issues
       -  Campus/Stub AD aggregate vs.  end-user feedback
     o Issues raised:
       -  high speed counting
       -  fraud
       -  credit limits
       -  cooperation between stub and backbone networks
       -  how heterogeneous can the models be?
       -  interaction with congestion control, access control, routing
     o Liaison Activities
       -  IETF Internet Accounting
       -  SMDS Accounting
       -  OSI Accounting
     o Suggested Experiments
       -  Flow-based instrumentation (use this to identify and play
          with flows)
       -  Resource reservation (We should suggest ST-2 or MacHip, a
          St.  Louis sponsored entry)
       -  Instrument applications to provide feedback window (have a
          window with a * amount to meter applications)

3. OPEN DISCUSSION
   END-USER FEEDBACK - Can end-users influence policy?  How about the
   ability to provide accounting feedback mechanisms to network users
   real-time as they use it, what that might look like and so forth?
   [Ed.  This is somewhat orthogonal to the group charter at the
   application level, but was an interesting discussion worth keeping
   in mind.]
   POLICY-BASED ROUTING - Their relation to us is in their use of the
   IP header's options field.  We might put in a Kerberos-style
   identifier that associates a particular machine/user/virtual
   circuit with a unique token.  This scheme might work between
   adjacent networks to track FLOWS though them, but would be
   difficult (!!!)  to pull off on an internet-wide basis.  Some one
   or two of us should attend the policy-based routing sessions
   regularly since they're working on similar problems.  Negotiating
   quality of service is in the province of policy-based routing?
   GRANULARITY OF DISTINGUISHABLE ENTITY - Two positions were
   discussed:
   (a) IP-based accounting with only existing IP header information is
       sufficient.
   (b) One should try to accommodate users and perform accounting by
       the user-id where it is feasible.
   IDEAS ON IDENTIFYING THE END-USER TO THE ACCOUNTING MECHANISM

   (a) PARSING TCP and APPLICATION LAYER PROTOCOLS FOR USER

                                 4






    INFORMATION? What about parsing more than the IP header?
    Considered untenable in a router.  Even if we dismiss the
    violation of protocol layering as "purist", we still must
    contend with higher processing overhead.  Hosts would still
    need to be modified to ensure that the user information is
    present.  But passive "watchers" like scopes could be employed
    on LANs.
(b) MODIFY THE IP HEADER TO ADD ACCOUNTING INFORMATION? We don't
    believe it'll get implemented by all existing hosts.  (i.e.
    practically impossible).
(c) USE IP OPTIONS? Router perspective:  putting user-based
    accounting stuff in a router is too much processing overhead.
    Counter-Example:  Tymnet billing is on a per-user id.
    Compromise:  At a minimum, an IP packet that has user-level
    accounting information might be afforded a lower priority in
    the router's processing queue.
(d) VANISHING OPTIONS? Vollbrecht points out that router-to-router
    accounting and ES - IS accounting are separable problems.  This
    led to a discussion of how to leave the user-id option in for
    the stub network's use and strip it from the header when
    sending the packet to the regional to reduce regional overhead.
    Still a performance issue, and what about the checksum?  This
    should be investigated more thoroughly.
    SERVERS - How does one account for mail that explodes at a list
    server?  Is it the responsibility of the host, the list, or the
    person who sends to the server?
    OSI ACCOUNTING - Since they're not defining meters yet, we will
    probably influence the OSI standard with our choices.

ADMINISTRATIVE DETAILS

(a) REVIEW OF CHARTER
     o Examine existing and hypothetical policies to understand
       what set of information is required to satisfy usage
       reporting requirements.
     o Define specifications of accounting meters, local storage
       requirements, and aggregation granularities.
     o Recommend a data collection protocol and representations for
       processingby accounting applications.
     o Develop test scenarios to verify model.
     o Guess we have to recommend mechanisms for formulating
       policy, though we don't want to sink in the policy swamp.
       Also need to consider implementation issues since they are
       practical and affect the ``reasonableness'' of
       recommendations.
(b) Internet Accounting Action Items
    Can we live with the proposed schedule?  Sure.
    The following areas should be addressed in preparation for the
    August 1990 IETF meeting except where otherwise noted.

                              5






o Outline of Meter Service Document => C.Mills
o Architecture Discussion => Mailing List
   - Levels of Metering (Do we have the right model?)
   - Define Meters
     * Entities (Done.  Review only.)
     * Quantities (Done.  Review only.)
     * Time of Day (Further development.)
     * Quality of Service (How to approach this?)
o Liaison Activities
   - ANTF => Z.Su
   - OSI Accounting => B.Handspicker, M.Seger
   - SMDS => Z.Su
o Explanation of Concepts (writeups due to mailing list)
   - R.Reschly suggested that accounting on a backbone is the
     integral of bandwidth utilization and that proportional
     utilization rather than absolute measure is a useful
     measure.
   - J.Galvin proposed to write up some of the discussion.
   - M.Roselinsky will expand upon the user-id/cookie for the
     IP options field.
   - C.Mills will summarize the applicability of policy-based
     to accounting.
   - D.Hirsh will summarize current policy/practice in the
     internet community (eg digest the FARnet study,
     summarize BBN/SRI activity, etc.)  in light of the
     proposal for meters.  (First step towards test
     scenarios.)
o Unassigned Tasks (may be deferred) => Mailing List
   - Define Accounting Log Formats
     * Local Storage Requirements
     * Compatibility with Existing Protocols
   - Develop Testbed/Prototypes



                         6






ATTENDEES
    Peblo Brenner             sparte!pbrenner@uunet
    Martina Chan              [e-mail]
    James Galvin              [e-mail]
    Don Hirsh                 [e-mail]
    Keith McCloghrie          sytek![e-mail]
    Robert Reschly            [e-mail]
    Milt Roselinsky           cmcvax![e-mail]
    Mark Seger                [e-mail]
    Brad Strand               [e-mail]
    Zaw-Sing Su               [e-mail]
    John Vollbrecht           [e-mail]



                              7